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Abstract 


A new metluxl for software specification is described in A Message Based Specifica- 
tion System For Object Oriented Software Construction [Sar96]. It represents the 
system's specification in a formal language. The specification consists of two models, 
an Object Model and a Message Model. Classes and relations between classes are 
given in the Object Model. The dynamic interactions between objects are given 
in the Message Model. In this thesis we develop a tool that will translate such 
analysis/design specification into an implementation in C++. This tool will produce 
C++ headers and code for the methods, where feasible, from the information given 
in these models. We provide a library for maintaining the persistence of objects in 
the system. 
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Chapter 1 


Introduction 


1.1 Introduction 

Information systems are being developed by using numerous methodologies, tech- 
niques and tools. These methodologies and tools have been developed since the be- 
ginning of the computer era to support the demand for computer based information 
systems. To develop a large and complex system successfully, a good methodology 
and proper tools are essential. A recent trend of viewing systems as collections 
of identifiable, interacting objects has the potential to initiate a new revolution in 
information systems development. 

Broadly there are two kinds of methodologies namely Structured Design method- 
ologies and Object Oriented methodologies available in the software engineering 
world. Several 00 methodologies are being used for software development these 
days. Object Oriented Methodologies are still evolving. Some of the well known 
methodologies in the 00 paradigm are by Booch, Rumbaugh’s OMT, Jacobson’s 00 
Software Engineering. It is found that software developed by the 00 methodology 
is extendible, reusable and easily maintainable. That is the reason why the 00 
paradigm is being widely used. 

In addition to following a methodology to develop a system, the usage of tools 
that translate the specification to an implementation enhances the productivity 
and quality of the software. There exist many such tools for existing well known 
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methodologies. These tools generate code that satisfies all the design constraints 
that ensures the reliability of the software produced. 

The essentia! characteristics of object-oriented system development methods are 
Abstraction. Encapsulation, Modularity and Hierarchy. According to Booch [Boo94] 
without support for these elements, a model is not object oriented. An object 
oriented language like C-h-b provides necessary support for the implementation of 
these principles. 

A new message centric 00 m<‘thod is described in .4 Message Based Specification 
System For Object Oriented Software Construction [Sar96]. In this method a formal 
language has developed for specifying .software modules(the analysis/design 
specification). In ihi.s thesis we <leveloped a translator which takes such a specifica- 
tion and gen<‘rates C-I-+ code for the specified software module. 

Classes, Objects and messages/methods are central to the development of object 
oriented software. .A clas.s is a definition of a concept with all of the data items 
and the operations on that data encapsulated within it. A class generates objects 
{specific instances) that contain the data and operations for that instance of the 
class. An operation on data defined within a class is referred to as a method. An 
object can invoke a method in another object by sending a message to that object. 

This method emphasizes both the static structure and dynamic behavior of the 
sysUnn being modelled. Most <‘xisting methods place too much emphasis on defining 
the static structure of tlie system. The analysis/design specification is represented 
by a formal textual notation, independent of any programming language. 

1.2 Motivation 

A Message Based Specification System is a new method, that differs from the existing 
methods. The aim of this thesis is to develop a tool that will translate the spec- 
ification produced by this new method into an implementation. The specification 
produced in this message based method, mainly, contains two parts, an Object Model 
and a Message Model In the Object Model the static structure of the system is 
specified. Classes, their attributes and relations between these classes are given the 
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Object Model of the specification. The behavior of the objects is not specified in 
the Object Model. The behavior of the objects is implicitly specified in the Message 
Mode! of the sp<Tification. The Message Model gives message passing scenarios 
betwetm the objects of the system, in terms of Processes and Sub-processes. 

In this thesis, we develop a tool, which automatically generates C++ headers and 
code for the methods of tlie objects, where feasible, from the information specified 
in these 0!>ject anti Message Models. This tool also generates code for each class to 
maintain the i)ersistence of objects. 

This kind of tool enhances the productivity of the system and quality of the 
software produced. Manual translation of the analysis/design specification into 
implementaliort is an error prone, tedious and time consuming process. 


1.3 Overview of the Thesis 

This section briefly describes the remaining chapters and appendices. Chapter 2 
gives a brief tiescription of concepts of the methodology and syntax of the spec- 
ification language. Chapter 3 describes rules of translation. Chapter 4 gives the 
implementation details of the translator. Chapter 5 gives concluding remarks and 
limitation.^. Appendix A gives persistence library, a library for support of object 
persistence. Appendix B gives template library. And appendix C gives the notation 
of the methodology in BNF. 
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Chapter 2 
Methodology 


In this chapter we introduce the concepts of message based specification language 
and give a dtHailtKi dt'scriplion of the notation. The notation is informally specified 
(The formal si>ecification given in Appendix C). The DOAA Office Automation 
example will be used to explain various concepts in this chapter. 

2.1 Concepts of this Method 

In this tnethod th<* system is viewed as a collection of objects communicating with 
each other. Each ol)j<'ct has .some data that constitute its state and some rules that 
tell when to s(‘n<l a message, when to receive a message and what to do when a 
message is received . As all these rules involve messages, the rules are specified with 
the message rather than with the object. 

Below, some basic terms that are used in this method are explained. 

Object An Object is an abstract or real world entity which has state, behavior and 
identity, and communicates with other objects. 

State The state of an object at any instant consists of its knowledge about itself 
and its knowledge about the environment at that instant. 

The knowledge about itself is represented by the values of the attributes of that 
object. The knowledge about the environment is represented by the messages 
it transacts. 
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message A message forms the unit of communication between two objects. 

A message i.s an asynchronous message as in Actor systems. But not in the 
same sense as the term is used in many 00 Programming Languages (which 
is essentially a method invocation). There is a difference between method 
invocation and message. Method invocations are nested (which makes them 
synchronous), where as messages are not nested (Asynchronous). 

The message is defined by the sender, receiver, message identifier and the 
arguments for the message. Also specified along with the message are Pre 
con<litioiis ((’onslraints on the state of the sender to send the message), Post 
comiitions (Constraints on the state of the receiver to receive the message) 
and .Act ion to b<* performed by the receiver on receiving that message. 

A message can be understood as a command or request one object gives to 
another object to do some action. Messages are used to represent dynamics of 
the system in this Method. 

Process A Pro<-ess is a sequence of events that happen to make a meaningful real- 
world functionality. 

A Proc<*s.s can be viewed as a thread of activities. For example, in the DOAA 
Office atitoniation system. Registration process starts with DOAA sending 
Regi.stration notification and ends with Student’s Roll Number being entered 
in the Rt)ll.s. 

Processes and objects are two central concepts of this method. In the first 
stage (requirements specification) there will be only processes but no classes 
or objects. In Analysis and Design stages there will be both classes, objects 
and proces.ses. And in the implementation there will be only objects but no 

processes. 

In requirements specification, processes are represented by plain English sen- 
tences. In Analysis and Design stages processes are represented in terms of 
messages and sub-processes, which again are represented in terms of messages. 
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Generic process and Generic message Generic process is the mechanism by 
which we can represent similar turn of events once and reuse it later. Similarly 
generic messages can he used when similar messages are being sent to different 
objects. 

Generic Processes are used to capture commonalities in the system. For 
example, most of the queries have same pattern of events : An object A 
requests for some data in objectB. object B extracts the data and gives the 
result. s to object A. Here, except for the participating entities, the sequence of 
events is same. So. this can be treated as a generic process. 

Sub Process Sub process specification is useful to handle complexity. Large pro- 
cesses can be ih'composed into sub processes. Generally if there is one central 
object that interacts with several objects to do an operation then we put these 
interactions into a sub process. 

For example, when Grade reports for all courses reach DOAA, he does “Prepa- 
ration of Students' grade sheets'’ sub process. This sub process involves 
processing tin* Course grade lists to prepare grade sheet for each Student for 
the courses he took in that semester, calculating CPI for each Student using 
CPI Rule from Rule Book, calculating Student’s status for the next semester 
(RtJgular / Probation / Warning etc.) and finally sending the prepared grade 
sluxfts to Departments. DOAA performs this sub process by getting data 
required from Rule Book and Student. 


2.2 Notation 

2.2.1 Object model 

The object model is used to represent the static structure of the system. There are 
three kinds of objects in the system : entity objects, interface objects and control 
objects, entity or data objects are used to store information. They usually exist in 
the problem domain and represent some real- world entity or concept. Interface ob- 
jects are used to view data in entity objects. Control objects are used to collaborate 
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between several entity and interface objects. The notation for entity and control 
objects is same and is different from notation for interface objects. 

I Clans Specification 

This specification is valid for entity and control objects. 

CLASS : Same of the class. 

Same of the rla.'is is an identifier^ This declaration begins declaration of a new 
class. All (he items that follow this declaration are assumed to belong to this class. 
Only another “(’L.ASS : xxx" or end-of-file will end the declaration of this class. 

TYPE : /l/i6’77e.-irr . 

this field is optional, if nothing is specified about the TYPE, then it will be 
taken as non- abstract data class. 

An abstract class is one which does not have any instance. A class can be an 
abstract class only if it is a base class of an inheritance hierarchy. 

For example, in the DO A A system. Person is an abstract class whose derived 
classes are STUDENT, FACULTY.MEMBER, DOAA etc. A class derived from an 
ab.stract cla.ss can itself be an abstract class. 

INHERITS : class name [, class name ...] 

The list of classes from which this class inherits. 

ATTR : attr.name <type> [, aitrjname <type> ...] 

list of attributes each specified as attribute-name <type>. type can be any of 

• STRING, NUMBER, DATE., etc. (i.e. scalar type) 

• [ attr.decl ] (represents list) 

• TABLE [ attributes list ] (a table) 

• { attributesJist } ( set of dissimilar but related items) 

^Syntactically, an identifier begins with a letter [a-zA-Z_] and contains any alphanumeric 
character (including ). 
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Examples : Person has attribute name. 

name <STRING> 

Grade.Sheet has table of course number and grade. 

grades Ji-it < TABLE [conrse.no <STRING>, grade <CHARACTER> ] > 

GENERALIZATION OF : class.name [, class.name ...] 
class.nnmt f. class.name . . .] are classes which inherit this class. 

AGGREGATION OP : 

(lass name (multiplicity) [, Class name (multiplicity) ...]. 

RELATED WITH : 

IhlatedClass name (relation.name, multiplicity) 

[. RelaiedClass name (relation.name, multiplicity) ] 

iTlation.namc is the role the related object plays with respect to this object in 
the relation. specifies how many instances of the RelatedClass are related 
with one instance of this clas.s. 

I Interface class specification 

The specification of interface classes differs from that of control and entity classes. 
Details on the specification of interface classes are given in [Sar96]. 

Only certain fields of interface class specification are considered in the translation 
of analysis/design specification to C++ headers. For each interface class, name of 
the class, class type, and related class should be specified. 

Eg: 

Suppose class COURSEJNTERFACE is an interface class for COURSE class. 
Specification of the interface class COURSEJNTERFACE should be 
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CLASS : COURSE. INTERFACE. 

TYPE : INTERFACE. 

RELATED WITH : COURSECinterfacefor , 1) . 


2.2.2 Message model 

process procms.namr. 

sub process :: ,sub.proc(s$^nam€. 

we something into sub processes when there is a central object that is 

gathering <lata from several objects to do certain operations. 

generic sub process :: genericsnb.process (parameters). 

INPUTS : parameters.varyingJor_genericjsub_process. 

The declaration of a set of messages begins with one of the above three process, 
sub process or generic sub process declarations. 

FROM : Class name. 

TO : Class name (constraint}. 

Class name is the name of the class specified in the object model. 
constraint can lx* 

• condition on some attribute of the object. This is used to identify particular 
instance of the class. 

(variable == class:: attribute) 

(class::attributel <=> class::attribute2) 

• ALL, meaning all the instances of the class should be used for the purpose. 

• ALL-RELATED, meaning all the instances receiver class related to this object. 

• handle == ref 
handle == BACK 
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The abo\e means that we explicitly give the handle (^handle identifies an object 
in the s> stein. L\ery object will have an unique handle. In the context of a 
Programming language like C + +, handle is same as reference. In the context 
of a DatabaM*. handle is the primary key) instead of fetching it from the 
relations of t he sender object. 

When the handle is BAC’K, this means that the sender should not pick up the 
object handle from its Relations table, but should just send it, as a response 
to the int’ssage it received, to the corresponding object. For example, any 
Student can <}U<‘ry a (’ourse for its details. Then the Course will extract the 
details ami semis it to Student. While replying, if we specify the Constraint as 
navir ~~ jj/, (’ourse will just sw whether the Class STUDENT is related to 
it and chei'ks whether this particular STUDENT exists in its Relations table. 
If not so, it will not send the message. So, we should specify that even though 
this Slud<*nt is not related to the Course, it knows his address through the 
prior request. 

msg-id : mrssagr identifier (parameters). 

The synla.x of tntsitage identifier is same as that of class name in Class speci- 
cation. 'I’lu* syntax of the parameters is the same as syntax of “list of attributes” 
s {lescribed in the Class specifications. 

msg-type : type of the message. 

type of the message can be reply, shared or exclusive. 

reply means the message is being sent as a reply to a message this object has 
previously received. The sender of the request message expects and waits for this 
reply message, 

shared and exclusive represent the security level of the message. If it is specified 
as exclusive, then only this object can send the message to the receiver. If it is 
specified as shared, then other objects can send this message to the receiver only 
if security level in that message specification is also specified as shared, shared is 
useful to restrict the senders to a set of objects. 
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msg-cond : constraint that does not depend on the state of the sender, to send 
the message. 

This is nsod to send a message repeatedly (looping of the message) or send a 
message depending on some condition which is not associated with the state of the 
object. 

Example : 


• if (variable == value) 

• foreach item (tahU*_name or lisl_name) 

result : rrp/r/ to this message 

The syntax of “result” is similar to that of list of attributes. 

When you specify the “result”, it means that the sender “expects” some response 
to this message. This response is the result of action taken by the receiver of the 
message. 

PRE>COND : condition on the state of the sender before sending the message 

POST-COND : condition on the state of the receiver befoit receiving the mes- 
sage 

It is the combination (and/or) of one or more of the following things. 

• received msgJd [of processJd] 

• received result_of msgJd [of processJd] 

• sent msgJd [of processJd] 

• attribute <=> value 

• attribute! <=> attribute2 

The Pre condition is a constraint on the state of the sender to send the message. 
Post condition is a constraint on the state of the receiver to receive the message. 
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By specifying clifTerent Post conditions for the same message exchanged between 
the same two objects, we can have different actions depending on when the message 
is received. Other use of Post condition is to decide whether to accept or reject the 
message dep<‘nding on its time of arrival. 

For Exam{)le, when a stmlent sends a registration form request to DPGC, de- 
pending on wheth«*r he had received Registration forms from DOAA or not, he will 
process the message or ignore it. 

While coding. Ptr romUtion is generally useful to position the function call. 

Pre and I’ost <‘omlitions are also important for testing purposes. 

Action : nrtiou io hr takrn after this message has been received 

Action can be any of the following 

• send message msgJd [of processJdj 

• do sub-process sub.procJd (parameters) 

• send generic message msgJd {TO:value, FROM:value, . . . etc.} 

• do generic sub-process process Jd (parameters) {values to substitute} 

• select menu item .xxx 

“.select menu -item xxx” can be used only if the receiver is an Interface object. 

generic message :: 

declaration of normal message, except that some fields will be empty. 

I Comments spedJScation 

Finally, any text beginning with a # character upto the end-of-line is considered a 

comment in all specifications. 
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2.3 An example 

2.3.1 Description of Doaa Office 

DOAA Offict' dealB with all the academic activities in the Institute. Registration of 
Students, Degree awarding, new Courses approval, Student’s performance evaluation 
each semester, etc. Here we represent Registration process in detail. 

Registration involves clearing the Institute dues, Hall dues. Academic registra- 
tion and final registration. .Academic registration for next semester is done before 
the en<i of the current semester. Dues clearing and final registration are done only 
during the specified dates, at the beginning of the semester. 

For .Aciuiemic registration, DOAA .sends a notice giving the dates of registration. 
List of offered co»ir8«*s is put \jp on the notice boards. A student fills in a registration 
form available from the Con%‘ener, DUGC/DPGC depending on whether he/she is 
UG Student or PG Student. The student then selects his courses of interest from the 
list of courses offered (Courses may be compulsory or electives). Instructor selects 
some students depending on his selection procedure (for some elective courses the 
instructor's approval is required). After filling the registration form, student submits 
it to Convener. signature. 

Dues ci«‘arance is dotie by paying outstanding dues to the institute. 

For final registration. Student submits Registration form to DOAA’s office. 
DOAA office checks whether stmhmt has cleared dues or not, whether he is aca- 
demically eligible for registration, and enters the Student’s roll number on rolls. A 
Student is registered when his roll number is entered on rolls. 

2.3.2 Requirements Specification 

I Registration Process 

DOAA sends registration notice to notice boards. 

DOAA sends registration forms to Conveners, DUGC/DPGC. 

Student requests DUGC/DPGC for registration form. 

Student sees notice board for list of offered courses. 
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Student (I'G) fills the registration form with the core courses and electives. For 
each course he selects, student requests course instructor for approval to credit that 
Course (if that <-ours<* requires instructor's approval). 

Student fills the Registration form and gets DUGC/DPGC’s signature. 

For clearing dues, the student pays the dues and gets receipt(s). 

Finally, student submits the Registration form and these two receipts in the DOAA’s 
Office. 

.After receiving the registration form, DOAA’s office checks whether the student 
is academically eligible for registration or not. If he is eligible, then the student is 
deenwxl to have r<'gist<‘red. 

2.3.3 Initial Domain Object Model 

Looking at <lescription of the system, we find some obvious objects like STUDENT, 
COURSE, DOAA. DEPARTMENT. DPGC, DUGC, etc. 

STUDENT will have attributes name, address, rolLno. etc. name and address are 
attributes for DOAA. DUGC, DPGC also. So, we can generalize these classes to 
form the PERSO.N class, whose attributes are name, address. 

The complet<* obj<‘ct mode! is given below. 

2.3.4 Object Model 
I Class Specifications 



CLASS : PERSON. 

TYPE : ABSTRACT. 

INHERITS : PERSON. 

GENERALISATION OF : STUDENT, FACULTY.MEMBER . 

ATTR : name <NAME>, 

enail..addr <EMAIL>, 
address <STRING>. 
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CLASS : STUDENT. 
type : ABSTRACT. 

INHERITS : PERSON. 

GENERALISATION OF : UG.STUDENT, PG STUDENT. 

ATTR : roll.no <NUMBER>. 
address <STRING>, 

joining.date <DATE>, #date of joining the institute 
semester < NUMBER >. # Academic semester for student 
REUTED WITH : COURSE (takes, N) , 

PERFORMANCE.RECORD (has, 1). 

# 

CLASS : UG.STUDENT. 

INHERITS ; STUDENT. 

ATTR : acad.status < STRING >, # regular/ warning/probat ion .. etc. 
RELATED WITH : DUGC (CONVENER, 1). 



CLASS : PG .STUDENT. 

TYPE : ABSTRACT. 

INHERITS : STUDENT. 

GENERALISATION OF : MTECH.STUDENT, PHD.STUDENT. 

ATTR : leave.status { casual.leaves <NUMBER>, sick.leaves <NUMBER>, 

vacation.l eaves <NUMBER> } 

# 

CLASS : MTECH.STUDENT. 

INHERITS : PG.STUDENT. 

RELATED WITH : DPGC (CONVENER, 1). 

THESIS.SUPERVISOR (Th.guide, 1), 

TA.SUPERVISOR (Ta.instr, 1). 

# 

CLASS : PHD.STUDENT. 

INHERITS : PG.STUDENT. 

RELATED WITH : DPGC (CONVENER, 1) , 

THESIS.SUPERVISOR (Th.guide, 1), 

PHD.ACAD.DETAILS (acad.details, 1). 

# 

CLASS : REG.FORM. 

ATTR : year< number>, 

S€m< aumber>, 
roll.no< nu«ber>, 
room.no < string >, 
student .name<STRING> , 

Thesis.supervisor<STRING>, 

Financial.Asst <string>, 

DPGC.sign<signature> , 

DUGC.sign <signature>, 
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courses < TABLE [ course_no <N0MBER>, c.uaine <STRING>, 

units <number>, instructor <string> ] >. 

# 

CLASS : FACULTY.MEMBER. 

INHERITS : PERSON. 

GENERALISATION OF : COURSE.COORDINATOR, CONVENER, DOAA. 

ATTR : pf.no <NUMBER>, 

leave.status {. casual_leaves <NUMBER>, sick.leaves <NUMBER>, 
vacation_leaves <NUMBER>}. 

# 

CLASS : COURSE. 

ATTR : 

c.no <nuinber> , 
c.name <string>, 
units.pg <number>, 
units.ug <number> , 
syllabus <string>, 
references <string>, 
approval_date <date>, 
lab <nuinber>, 
lecture <number> , 
tutorial <number>, 

course. slots < TABLE [ time_slot<time>,day<string>,rooni_no<string>] 

RELATED WITH : COURSE.COORDINATOR (taught _by, N) , 

STUDENT (enrolled.by, N) . 

# 

CLASS : COURSE.COORDINATOR. 

INHERITS : FACULTY.MEMBER. 

RELATED WITH : COURSE (teaches, N) . 

# 

CLASS : CONVENER. 

TYPE : ABSTRACT. 

GENERALIZATION OF : DPGC, DUGC. 

RELATED.WITH ; RULE.BOOK (Rules.store, 1) . 

# 

CLASS : DPGC. 

INHERITS : CONVENER. 

# 

CLASS : DUGC. 

INHERITS ; CONVENER. 

# 
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CLASS : DOAA. 

INHERITS : FACULTY. MEMBER. 

RELATED WITH : DPGC (DPGC, 1), 

DUGC (DUGC, 1), 

RULE.BOOK (Rules.store, 1) . 



CLASS : NOTICE. BOARD. 
aggregation of : NOTICE (N) . 



CLASS : NOTICE. 

ATTR : date <DATE>, 

issued.by <STRING>, 
title <STRING>, 
text < TEXT>. 

# - 

CLASS : RULE.BOOK. 

REUTED WITH : RULE (has, N) . 

I 

CLASS : RULE. 

ATTR : rule. id <STRING>, 
w.e.f <DATE>, 
eff.upto <DATE>. 
rule.func <FUNCTION>. 



CLASS : TIME.TABLE. 

ATTR : time.table < TABLE [ c.no <NUMBER>, Instructor <STRING>, schedule 

<TABLE [ day <STRIMG>, time.slot <[TIME]>] > ] >. 
REUTED WITH : DEPARTMENT ( Belongs.to , 1) . 

« 

CLASS : DEPARTMENT. 

REUTED WITH : 

STUDENT ( Has , 1-H) , 

FACULTY ( Has , M“N) , 

NOTICE.BOARD ( Has . 1-1) , 

TIME.TABLE (Has, 1-1). 


# 

CLASS : ACCOUNTS .SECTION. 

INHERITS : GENERAL. ADMINISTRATOR. 
# 


17 



CLASS : HALL.OFFICE. 

INHERITS : GENERAL. ADMINISTRATOR. 

i - 

CLASS : CALENDAR. 

ATTR ■■ calendar <TABLE [ date <DATE>, event <CALENDAR_EVENT_TYPE> , 

semester <STRING>3 >, 
current.sem <SEMESTER>, 
current.year <YEAR>. 

# 


I Ohjvrts spodficHtion 

i - 


CLASS 

TYPE 

REUTED WITH 




STUDENT. INTERFACE. 

INTERFACE 

A.D.FORM.INTERFACE ("uses'*, 1-1), 
STUDENT ("attached to", 1-1). 


CLASS : REG.FDRM. INTERFACE. 
TYPE : INTERFACE. 

RELATED ; REG.FDRM 

t 


CLASS : DOAA. INTERFACE. 

TYPE : INTERFACE. 

RELATED WITH : DOAA. 

# - 


CLASS : COURSE.COORD.INTERFACE. 

TYPE : INTERFACE. 

REUTED WITH ; COURSE.COQRDINATOR(coord,l) . 
# 


CLASS : NOTICE. INTERFACE. 

TYPE : INTERFACE 

REUTED WITH ; NOTICE (notice, 1) . 
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2.3.5 Message Model 
I Registration process 


process : : Registration. 

g # 

FROM : DOAA.INTERFACE. 

TO : SELF . 

msg_i<i : prepare_reg_notice () . 

Action : do generic sub.process make .notice {FROM : $FROM, 

res.message : reg_notice} 

result : reg.notice <N0TICE>. 

FROM : DOAA. INTERFACE. 

TO : DOAA . 

msg_id : send_reg.notice_to_depts (reg.notice <N0TICE>) . 

PRE.COND : received resultof _prepare_reg_notice. 

Action : send message notice.for.registration. 

FROM : DOAA . 

TO : CONVENER (ALL). 

msg_id : notice_for_registration (reg.notice <N0TICE>) . 

Action ; do sub.process store.notice. 

FROM ; STUDENT. INTERFACE. 

TO : STUDENT. 

msg_id : get.reg.form () . 

Action : send message req.for.reg.form {FROM: STUDENT, TOrCONVENER} 

FROM : STUDENT. 

TO : CONVENER. 

msg.id : req.for.reg.form () . 

result : res.val {reg.form <REGISTRATION_FORM>, remarks <STRING>}. 
Action : do sub.process check.eligibility.for.reg. 


# sending message to abstract class 'CONVENER' means sending to one of the 

# derived classes. 

FROM : STUDENT. 

?0 : REGISTRATION.FORM. 

msg.id : f ill.form (values <STRING>) . 

msg.type : exclusive. # this type takes care of security. 

FROM : STUDENT. 

TO : CONVENER. 
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BSg_id : sigii_reg>fonn (reg.fom <REGISTRATION_FORM>) . 

result : reg.fona <REGISTRATION_FDRM>. # signed registration, form. 

Action : do sub^process check_and_sign_reg_form 

(reg.form <REGISTRATION_FORM>) . 

FROM : STUDENT . 

TO : DOAA . 

msg.id : req_for_reg (reg_form <REG I STRATI 0N_F0RM>) . 

result : remarks <STRING>. 

Action : do sub.process process_the_reg_form. 

# # 

sub process : : proces8.the_reg_form. 



FROM : DOAA . 

TO : SELF . 

msg id : extract .details (query = "roll.no" <STRING>, reg_form 

<REGISTRATION_FORM>) . 

# extract.details should be taken as a general purpose message 
result : roll.no <NUMBER>. 

FROM : DOAA. 

TO : HALL.OFFICE. 

msg. id : check.student.for.dues (roll.no <NUMBER>) . 

result : paid <BOOLEAN> . 

if (paid — TRUE) { 

FROM : DOAA . 

TO : ACCOUNT.SECTION. 

msg. id ; check_student. for. dues (roll.no <NUMBER>) . 

result : paid.instt.dues <BOOLEAN>. 


if (paid.instt.dues == TRUE) { 

FROM 
TO 

msg. id 
Action 


} else { 


: DOAA. 

: SELF. 

: form.links (). 

• do sub process form.assoc.between.stud.course 

( reg.form <REGISTRATION_FORM» . 
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FROM 

TO 

msg.id 

msg.type 


DOAA. 

STUDENT (BACK), 
reply to_req_for_reg 

reply . 


(remark = "Instt. 
<STRING>) . 


dues not paid" 


} else { 


FROM 

TO 

msg_id 

rosg_type 


DOAA. 

STUDENT (BACK). 

replyto.req.for.reg (remark = "Hall duejs not paid" <STRING>). 
reply. 


} 




sub process : : form_associ at ion_between_ student _course. 

# # 

FROM : DOAA . 

TO : SELF. 

msg_id : extract .details (query » "roll.no, courses" <STRING>, 

reg_form <REGISTRATION_FORM>) . 

result : {roll.no <NUMBER>, courses <TABLE Cc.no <STRING>, c.name <STRING>, 

units <NUMBER>, instructor <STRING>]>}. 


foreach c.no (courses) { 


FROM 

TO 

msg.id 

rasg.type 

result 


DOAA. 

COURSE (c.no COURSE: : c.no) . 
give.handle () . 
shared . 

course.ref <HANDLE>. 


FROM 

TO 

msg.id 

msg_type 

result 


DOAA. 

STUDENT (roll.no == STUDENT: : roll.no) . 
give.handle () . 
shared. # for security 
student.ref <HANDLE>. 


FROM : DOAA . 

TO : STUDENT (roll.no == STUDENT: :roll_no) . 


I I. T., fC/ 
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msg.id : fom_assoc_with_course (course.ref <REFERENCE>) . 

msg-type : exclusive. 

FROM : DOAA. 

TO : COURSE (c.no «* COURSE: :c_iio) . 

msg.id : f onn_assoc_with_student (studeut.ref <REFERENCE>) . 

msg_type : exclusive. 

} 

#--- 

sub process ; ; chaiige_the.reg.fona. 

# — # 

FROM : STUDENT 

TO : SELF 

msg.id : retrive.reg.form ( constraints <STRING> ) 

result : reg.form <REG_FQRM> 

Action : send message modify.attr. 

FROM : STUDENT 

TO : SELF 

msg.id : modify.attr ( reg_form <REG_FORM>, 

values.string <STRING> ) 

# # 

sub process : : check.and.sign_reg_form. 

f # 

FROM : CONVENER. 

TO : SELF. 

msg_id : check_reg_form (reg.form <REGISTRATION_FORM>) . 

result : correct <BOOLEAN>. 

if (correct »» FALSE) { 

FROM : CONVENER. 

TO : STUDENT (BACK). 

msg.id : replyto.sign.reg.form (remarks = "Incorrect" <STRING>) . 

msg.type : reply . 
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} else { 


FROM : CONVENER. 

TO : REGISTRATION_FORM. 

BSg_id : put_dpgc_sign (signature <SIGNATURE>) . 

»sg_type : exclusive. 

} 



sub process : : check_eligibility_for_reg. 

# # 

FROM : CONVENER. 

TO : SELF . 

msg.,id : check_for_reg_notice (). 

result : present <B00LEAN>. 

if (received message reg_notice of Registration) { 

FROM : CONVENER. 

TO : STUDENT (BACK). 

msg_id : give.details ("status.desgn" <STRING>). 
result : details <STRING>. 

FROM : STUDENT. 

TO : CONVENER (BACK). 

msg^id : replyto_give_details (details <STRING>) . 

FROM : CONVENER. 

TO : RULE.BOOK. 

iosg_id : give_rale ("reg_elig_check_rule" <STRING>, desgn <STRING>) . 
result : rule <RULE>. 

FROM : CONVENER. 

TO : SELF. 

msg^id : apply^rule (rtile <RULE>, details <STRING>) . 
result : eligibile <B0DLEAN>. 

if (eligible == TRUE) { 

FROM : CONVENER. 

TO : SELF. 
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msg_id : 

create_reg_form () . 

result : 

reg.f ona <REGISTRATION_FORM> . 

FROM 

CONVENER. 

TO 

STUDENT (BACK). 

msg_id 

replyto_req_for_reg_form ( reg.form <REGISTRATION_FORM> 
remarks = "Eligible for Registration" <STRING> ; 

msg_type 

reply . 

Action 

do store (reg.form <REGISTRATION_FORM>) , 
do store.temp (remarks <STRING>) . 

} else { # eligible is FALSE 

FROM 

CONVENER. 

TO 

STUDENT (BACK). 

msg_id 

replyto_req_for_reg_form (reg.form <REGISTRATION_FORM> , 
remarks * "Not eligible for registration" <STRING>) 
# reg_form will be NULL. 

msg^type 

reply. 

Action 

do store (reg.form <REGISTRATION_FORM>) , 
do store.temp (remarks <STRING>) . 


} 

} else { # Registration notice has not been received from DOAA. 
# means it is not yet time for registration 


FROM 

TO 

msg.id 

’»sg_type 

Action 


CONVENER. 

STUDENT (BACK). 

replyto_req_for_reg_form (reg_form <REGISTRATION_FORM>, 
remarks = "not time for registration" <STRING>) . 

reply . 

do store (reg.form <REGISTRATION_FORM>) , 
do store_temp (remarks <STRING>) . 


} 


#- 
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I Generic processes 

generic sub process : : make.notice. 


INPUTS : ISSUER. 




FROM : ISSUER 

TO ; NOTICE. INTERFACE. 

msg_id ; make.notice (). 

result : res.notice <N0TICE>. 

FROM : NOTICE. INTERFACE. 

TO ; ISSUER. 

msg.id : replyto.make.notice (notice <N0TICE>) . 

“Sg-'type : reply . 

generic sub process ; : get.approval.f or.leave . 

” ^ 

INPUTS :: SUPERVISOR. 

FROM : STUDENT. 

TO : SELF. 

msg.id : get.Supervisor ( query.str = SUPERVISOR <STRING> ) . 
result : supervisor <FACULTY.MEMBER> . 

FROM ; STUDENT. 

TO : SUPERVISOR. 

msg_id : req.f or.leave.approval ( ) . 

Action : do sub.process store.request . 
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Chapter 3 
Translation 


In this chapter we describe the inipiementation phase and discuss how to translate 
each element of the specification into C++ code. The programming language C++ 
contains features like data encapsulation, derivation, virtuaJ functions, late binding 
and template mechanism, which make the implementation of general 00 concepts 
like data-hiding, generalization, polymorphism, meta data etc., easy. There is no 
feature in C++ that can implement association and aggregation directly. We discuss 
a suitable mechanism to implement asisociation and aggregation. 

The Message Ba,sed Specification Syst<'m gives Object and Message models of 
the .system. In the following s<?ctions we e.xplain how each statement of these models 
can be mapped to (,^++ code, 

3.1 Object Model 

The Object Model gives the static structure of the system. The classes presented in 
the system, their attributes and the relationship between the classes are specified in 
the Object Model. 

3.1.1 Class and It’s Attributes 

A class of this methodology is directly mapped to a C++ class. The attributes 
specified in this class become the data nnunbers of the C++ class. The default 
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accessibility of these data members is private. The accessibility of the data members 
of a generaiisted class is protected. Here we assume that all the attributes of 
the generaliz«‘d class are shared by the specialized classes. The generalization is 
implemente<l in (’++ using class derivation. 

We provide* a p«*r.sistent class. The derived classes of this persistent class are also 
persistent. For more information about the maintenance of persistent of the objects 
please see the .Vppendix A. 
l‘^9- 

Specification for Stnd<*nt Class 

CLASS : STUDENT. 

TYPE : ABSTRACT. 

INHERITS : PERSON. 

ATTR : roll .no <NUMBER>, 
name <STRING>, 

joining.date <DATE>, #date of joining the institute 
semester < NUMBER >. # Academic semester for studeni 


Translation of Student Class in C++ : 

class STUDENT : public PERSON ■[ 
publ ic : 
private : 

NUMBER roll.no ; 

STRING name ; 

DATE joining.date ; 

NUMBER semester ; 

>; 
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3.1.2 Association 

In the specification the association is represented by RELATED WITH field of a 
class specification. The concept of association has no direct counterpaxt in C++. 
The .Association between two objects can be implemented by using pointers. But the 
objects are persistent, so an object cannot have pointers to related objects residing 
on the disk. So. we have to use object-ids to maintain the association between 
objects. In each object, there should be a data member whose value can identify 
this object uniquely in the inheritance hierarchy of this object. We are using such 
object-id as such a data member. The mechanism that implements the association 
should ensun* r<‘f<’r<‘nt ial integrity between the linked objects. The association is 
always bi<lir«*ctioual. Each object will have a link to the related object. The link 
can be trav«‘rsed in both directions. 

In tlie implementation of association between objects, each object will have a 
list of object-ids of all related objects. When an object wants to send a message to 
another object, it has to get a pointer to the receiver object. The sender object uses 
the object-id of the receiver object to get a reference to the receiver object. 

For each association, in each related class there will be one private object member 
and two private methods, set and unset. This special object maintains the object- 
ids of the related objects. The methods set and unset are used to add and delete 
respectively an object -id of the related object . When a link is created /deleted the 
cardinality of the asssociation will be checked. If the cardinality constraints are not 
met an error will be reported. The functions 

• CreateLink 

• DeleteLink 

are used for linking and unlinking the objects. 

The function CreateLink(Object A, Object B) forms a link between objects A and 
B. The function DeleteLink(Object A. Object B) deletes a link between the objects 
A and B. These two functions are friend functions to both objects. These functions 
invoke the private methods, set and unset. Thus a link cannot be destroyed or 
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formed without using these functions. Using these functions to create and destroy 
the links enstires the referential integrity between related objects. 

Classes Stu<ient aiul ( ourse are related to each other. The specification of these 
classes is 


CLASS : STUDEHT. 

ATTR : . . . 

RELATED WITH : COURSE (myCours es , N) ; 

CLASS : COURSE. 

ATTR ; . . . 

RELATED WITH : STUDENT (credit edby, N) ; 


Translation of Student Class in C++ : 

class STUDENT { 

friend CreateLink(STUDENT COURSE ♦) ; 

friend DeleteL ink (STUDENT COURSE *) ; 

public: 
private: 

// other attributes 

KeysObject myCoursesKeys ; // maintains object-ids 
void set (COURSE *c) { 

myCoursesKeys .Add ( c -> GetKeyFieldO ); 

} 

void unset (COURSE *c) ■( 

myCoursesKeys .Remove ( c -> GetKeyFieldO ); 

} 

>; 
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Translation of Coursp (^la-ss in C++ : 


class COURSE { 

t 

friend CreateLinkCSTUDENT *, COURSE ♦) ; 
friend DeleteLink (STUDENT *, COURSE *) ; 
public; 
private: 

/ / other attributes 

KeysObject creditedbyKeys ; 
void set (STUDENT *s) { 

creditedbyKeys .Add ( s -> GetKeyFieldO ); 

> 

unset (STUDENT *5) { 

creditedbyKeys.Remove( s -> GetKeyFieldO ); 

} 

>: 


3.1,3 Aggregation 

Aggregation .staiui.s for a kind of part-of relationship between objects. Aggregation 
is a special kind of association. Aggregation is implemented in the same way as 
association. Whenever an object wants to send any message to it’s constituent 
object, it uses the object-id to get a pointer to the part_of or constituent object. 
Eg: 

A Window is an aggregation of Borders. Specification is 

CLASS : WINDOW . 

AGGREGATION OF : B0RDER(4) ; 
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Generated (\)<le is : 


class WINDOW { 
public : 

void AddBORDERC BORDER *b) { 
set(b) ; 
b -> SaveO; 

} 

List<BORDER ♦> *GetBORDERS() { 

List<BORDER ’*■> *1 » new List<BORDER *>; 

// get pointers to the related objects 
GetPtrsToRelatedObjects(theBORDERS, 1) ; 
return 1; 

} 

private : 

KeysObject theBORDERS; 
void sat (BORDER *b) { 

if(b) theBORDERS. Add ( b -> GetKeyFieldO ); 

} 

void unset (BORDER *b) { 

if(b) theBORDERS . Remove C b -> GetKeyFieldO ); 

} 

}; 


3.2 Message Model 

In the Message Model messages exchanged by system objects are specified. For each 
object of the system, we pick up the methods from the given message scenarios. The 
objects are viewed as servers responding to requests via message passing. Every 
message is a call to an operation or a return. An object can communicate with 
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an independent object if it knows it’s name or object identifier. In response to a 
message an object executes a sequence of primitive actions 

• Inquiring/Updating the local memory of the object. 

• Create new objects 

• Sending messages and receiving replies and 

• Return values as reply to the message 

In the following examples we explain how an object can send/receive a message 
to/from another object and to/from itself, how it gets a reference to the receiver 
object, and how it performs the actions specified in the message. 

3.2.1 Methods of a Class 

An object’s behavior cannot be specified in the Object Model, since it is a result 
of all the interactions the object has with other objects. This is captured by the 
Message Model. The basic idea which implements the sending and receiving of a 
message is; When an object A wants to send a message M to another object B, the 
object A invokes the method of B that comsponds to the receiving of the message 
M. 

For each message specified in the Message Model, the sender object will have a 
method that carries out task of sending the message, and the receiver object will 
have a method that carries out the task of receiving a message. Every method that 
corresponds to sending a message is an inline method containing code for checking 
the pre-conditions and a call to the method of the receiver object that corresponds 
to receiving the message. If the pre-conditions specified fail, it does not invoke the 
receiving method of the receiver object. After testing of the system, we can remove 
the sending method along with the pre-conditions, and directly call the receiver 
object’s receiving message method. 
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I Accessibility of the Sending and Receiving Methods 

For a concrete class all the sending methods are private and aJl the receiving methods 
are public. For an abstract class all the sending and receiving methods are protected. 
For interface classes all the sending and receiving methods are public. 

An abstract class does not have any instances. So it neither receive nor send 
any message. But in the Message Model an abstract class also send/receive some 
messages. In such cases the actual sender/ receiver will be any one of the sub classes 
and is known only at run time. This is possible in Ct+ as it provides dynamic 
binding and virtual functions. 

I Parameters of the Sending and Receiving Methods 

The arguments for sending method are 

• A pointer to the receiving object and 

• Parameters of the corresponding message. 

The arguments for receiving method are 

• A pointer to the sender object and 

• Parameters of the corresponding message. 


3,3 Implementation of various types of messages 

The messages exchanged between the objects are classified into two different types. 

• Normal message 

• Reply message 
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3.3.1 Implementation of Normal message 

An object may recei%’e a normal message from an object of any type. Tbe sender 
sends it’s reference along with the message parameters. It may be needed to 
communicate with the sender while servicing the request. 

Eg:l 

Suppose class receives message M with parameter pi and p2 of type int, from 
class B. And class .A sends message N to the class B. 

Generated co<le will be. 


class A { 
public : 

rcv.MCB *sender, int pi, int p2); 
private : 

send_N(B *rcvr) { rcvr -> rcv_N(this); } 

>; 


class B { 
public : 

rcv_N(A *sender) ; 
private : 

send_M(A *rcvr, int pi, int p2) { xcvr-> rcv_M(this, pi, p2); } 

}; 


Eg:2 

Suppose class A receives message M with parameter pi and p2 of type int, from 
dasses B and C. And class A sends message N to these classes(B, C). 
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class A { 
public : 

rcv_H(AbstractClass *sender, int pi, int p2) ; 
private : 

send_N(AbstractClass *rcvr) { rcvr -> rcv_N(this) ; } 

>; 


class AbstractClass { 
public : 

virtual rcv_N(A *sender) {>; // dummy method 

>; 


class B : virtual public AbstractClass { 
public : 

rcv_N(A *sender) ; 
private : 

send_M(A *rcvr, int pi, int p2) { rcvr -> rcv_M(this, pi, p2); X} 

} 

class C : virtual public AbstractClass { 
public; 

rcv_N(A *sender) ; 
private : 

send_M(A *rcvr, int pi, int p2) { rcvr -> rcv_M(this, pi, p2) ; } 

>; 


3.3.2 Implementation of Reply message 

The reply message is sent in response to a message. This is not implemented as a 
function call. The reply message is mapped to a return statement in the definition 
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of the method. The message parameters will become the return values. Eg: 


FROM : CONVENER. 

TO : STUDENT 

msg_id : give.details (); 

result : details <STRING>. 

FROM : STUDENT. 

TO : CONVENER (BACK). 

msg_id : replyto_give_details (details <STRING>) . 

Co<le of the receiver method of STUDENT for receiving the message give-details. 

STRING STUDENT :: R_give_details (CONVENER *sender) 

{ 

STRING details; 

// construct the details 
return ( details ) ; 

} 


3.4 Actions 

When an object receives a message, it may have to make some other calls to service 
the request of the sender object. What the receiver object has to do after reception 
of a message, is specified in the ACTION field of the message specification. There 
are precisely two types of actions. 

1. Send a message 

2. Do a sub process 
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I'ln' arlioii Stud a 77)tsfiagf is translated to a function call in the, definition of 
the r<“<"<’ivii 4 ’ nx’tluxi of the r<*<eiv<'r. Here the pre-condition of type received some 
viissapi is useful in identifying tlie <on<‘cf message to be sent. 

When (’OrHSH.COORDlNATOK receives the message gct.registered.studtnts 
from (X)UI?SK_( ’OOHDJNTKRFACE it does the action send message give.registered-siudents. 
'I'he sp<*fifiration is 

FROM : COURSE_COORD_INTERFACE. 

TO : COURSE.COORDINATOR. 

Msg^id : get_registered_studeiits ( course.no <STRING>) . 

result : registered_students<TABLE[student<NAME>,roll_iio<NUMBER>3>. 

Action : send message give_registered_ students. 

FROM : C0URSE_C00RDINAT0R. 

TO : COURSE (c_no = course_no) . 

msg.id : give^registered.students () . 

result : r6gistered_students<TABLE [student<NAME> ,roll_no<NUMBER>] > . 

PRE.COND : received get_registered_Btudents . 

The definition of tin* method that corresponds to the receiving of the message 
gct.regisfrnd.stvdnits in COURSE-COORDINATOR is 

COURSE.COORDINATOR: :R_get>registered_students(COURSE_COORD_INTERFACE *sender , 

STRING course.no 

) 

< 

/* performing the specified action 

send message give_registered_students */ 

// get pointer to the receiver 
COURSE *receiver; 
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GetPtrToOb j ect (receiver , course_no) ; 

registered. students • S_give_regist ered.students (receiver) ; 
retiira(registered_students) ; 


The action Do sub process is translated to a statement that invokes a private 
method that corresponds to this sub process. 

Eg:2 

In the Registration process when DOAA receives the message req.for-reg from 
STUDENT, it does the action do sub^process process.the.reg^form. The specification 
is 


FROM : STUDENT. 

TO : DOAA. 

msg_id : req_for_reg (reg_form <REGISTRATIOM_FORM>) . 
result : remarks <STRING>. 

Action : do sub.process process_the_reg_fonn. 

The definition of the method that corresponds to the receiving of the message 
reqjor.reg in DOAA is 

STRING DOAA : : R_req_for_reg ( STUDENT *sender, 

REGISTRATION.FROM reg_form 

) 

■c 

// Rest of the code to be filled. 

// Make a call to private method (sub.process) process_the_reg_form. 
process_the.reg_form() ; 

// Data to be sent to the caller of this method (Result) . 

STRING remarks; 
return (remarks) ; 

} 
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I How to get a reference to a receiving object 

Before sending a message to an object, the sender must identify and get a reference 
to the legal receiver object. The receiver object can be 

• a globally known object 

• the sender itself may become the receiver. 

• one of the related objects 

• some other object 

At any instance the receiver object may be in the memory ( active object) or 
on the disk ( passive object). We provide a routine which gives the pointer to an 
object given its object-id(key). This routine gives a pointer to the active object. If 
the required object is not active, it is made active and pointer to it is returned. 

Use of Receiver Constraints 

In the specification the type of the receiver object and the receiver constraints 
are given in the TO field of the message specification. 

If the constraint is ALL, the sender object sends the message to all the objects 
of specified type present in the system. We provide a routine that returns pointers 
to all objects of a specific class. 

Eg:3 


FROM ; DOAA.INTERFACE. 

TO : DOAA. 

msg_id : sen.d_reg_notice_to_depts (reg.notice <N0TICE>) . 

Action : send message notice_for_registration. 

FROM ; DOAA. 

TO : CONVENER (ALL). 

msg_id : notice.f or_registration (reg_notice <N0TICE >) . 

Action : do sub_process store_notice. 
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{he goiier.tt<'ti of I he method of DOAA corresponding to the message 
,^ni<Ur(i.n0tirfJojiti>t.<t receive*! from DOAAJNTERFACE is 


int DOAA : : R_send_reg_notic6_to_depts(D0AA_INTERFACE *sender, 

NOTICE reg_notice 

) 

{ 

List<CONVENER ♦> *rcvrList; // list of pointers to CONVENERS 
// get the list of ptrs to CONVENERS 
GetPtrsToObjects(rcvrList) ; 
ifCrcvrList »» NULL) { 

cout « “NO OBJECTS OF TYPE CONVENER \n’ ' ; 
return -1; 

} 

// send message to all CONVENERS 

Node<CONVENER *> *header » rcvrList->GetHeader() ;// list header 
while (header •- NULL) { 

CONVENER ♦revr - header -> GetItemO;// receiver pointer 
S_notice_.for_registration(rcvr, reg_notice) ;// sending message 
header ■ header -> GetNextO; 

} 

return 0; 


If the receiver constraint is ALL-RELATED the sender sends the message to all 
lated objects of the specified type. The related objects are just associated objects, 
ach object maintains object-ids(keys) of it’s related objects. 
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Eg:i 

Suppose (^Ol'RHE gets a request to give all the roll numbers of the students 
crediting that Course. Then COURSE has to get roll numbers from all related 
students. 


FROM 

; COURSE.INTERFACE. 

TO 

: COURSE. 

msg-id 

: give_credited_students_rollsC) . 

result 

: roll.numbers < [NUMBER] >. #list of numbers 

Action 

; send message give_roll. 

FROM 

: COURSE. 

TO 

; STUDENT (ALL.RELATED) . # All STUDENT objects 

# COURSE object. 

msg_id 

: give_roll_number() ; 

result 

: roll.no <NUMBER>. 

PRE^COND 

: received message give_credited_students . 


The generateti co<le for the method of COURSE corresponding to the message 
give-credited^studcnts-wlls receiv'ed from COURSE-INTERFACE is 

List<NUMBER> ^COURSE :: 

R_give_credited.students.rolls(COURSE_INTERFACE ^sender) 

< 

List<NUMBER> ^result = NULL ; // result 

List<STUDENT *> *STUDENTlist ; // list of ptrs to STUDENTS 
// get list of ptrs to STUDENTS 

// STUDENTkeys is a member object that maintains keys of STUDENTS 
QetPtrsToRelatedObiectsC STODEmeys, STODEMTlist ): 
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// sending message to all STUDEMTs 
Node<STUDENT *> ♦header = NULL; // list header 
ifCSTUDENTlist) header = STUDENTlist -> GetHeaderC) ; 
whileCheader) { 

STUDENT ♦recvr = header -> GetItemO; // receiver pointer 
NUMBER resultList item; // result expected 
resultListitem = S_give_roll_number(recvr) ; // sending message 
result .Append (resultListitem) ; // append to the result list 
header » header -> GetNextO; 

} 

return result; // send back result 


Sometimes the receiver has to send a message to the sender of some previous 
message it had received. The receiver constraint BACK is used to specify this 
situation 
Eg:5 

When a STUDENT sends message reqJor_regJorm to CONVENER, the CON- 
VENER .send.s back the message give_status to the student. 


FROM 


STUDENT. 

TO 

If* 

CONVENER. 

Risg_id 

* 

req_for_reg_f orm () . 

result 

• 

res_val reg_form <REGISTRATIQN_FORM> 

Action 


send give_status. 

FROM 

• 

CONVENER. 

TO 


STUDENT (BACK). 

msg_id 


give_statusO ; 

result 


status <STRING>. 

PRE_C0ND 


received message req_f or_reg_form . 
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The generated code is 


REGISTRATION.FORM CONVENER R_req_reg_from ( STUDENT *sender ) 

{ 

STRING status; // result expected 

status =» S_give_status (sender) ; // sending a message back 

} 


If the constraint is some Condition then the sender object has to send the message 
to all the objects of sp<‘cified type, that satisfy the Condition. The sender gets a list 
of pointers to the objects of specified type using the routine GetPtrsToObjecis. 

If there is no receiver constraint and if the sender class is related to the receiver 
class with cardinality one, then it is assumed that this related object is the receiver 
object. Each object has a key to its related object. It gets the pointer to the related 
object using the routine GetPtrToObject and sends a message to it. 

If there is no receiver constraint, the following cases are taken as specification 
mistakes. 

• if there is mor<i than one related object of receiver type 

• if the receiver object is un-related to the sender object. 


3.5 Sub Process 

A sub process is a group of interactions of an object with other objects. Finally 
each sub process is converted to a private method of the object that initiates the 
sub process. The result of the terminating message of the sub process becomes the 
return value of this method. 
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Eg:6 


sub process : : check_and_sigu_reg_form. 

FROM : DPGC. 

TO : SELF. 

msg_id : check.reg_fonn (reg_form <REGISTRATION_FORM>) . 
result : correct <B00LEA1I>. 

if (correct »» FALSE) { 

FROM : DPGC. 

TO : STUDENT (BACK). 

insg_id : replyto_sign_r6g_form (remarks <STRING>) . 

insg_type : reply . 

} else { 

FROM : DPGC. 

TO : REGISTRATIDN.FORM. 

msg.id : put.dpgc_sign (signature <SIGNATURE>) . 

} 

This sub-process is initiated by DGPC . This sub-process is mapped to a private 
method of DPGC . 

STRING DPGC : : check_and_sign_reg_f orm(REGISTRATION_FORM reg_f orm) { 
// select parameters 

REGISTRATION FORM reg.form ; 

// This is Private Method 
BOOLEAN condition; // result 

condition *= check_reg_f orm(reg_f orm) ; //sending the message 
if (condition == FALSE ) { 


44 



// sendiag result 
STRING remarks; 
return < remarks ) ; 

} 

else { 

// select parameters 
SIGNATURE signature; 

// select the receiver 
REGISTRATION.FORM recvr; 

//send the message 
S_put_dpgc_sign(recvr, signature) ; 

} 

} 
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Chapter 4 
Translator 


4.1 Implementation 

The implementation of the translator consists of, mainly, two stages 

• Parsing 

• Conversion 

4.1.1 Parsing 

Tools, Bison and Fltx are used to construct the parser. Bison is a parser generator 
and Flex generates lexical analyzers. 

The object model consists of all information on classes. A class-table is con- 
structed while parsing the object model. The class-table consists of information 
on all the classes specified in the object model. Generic-message and generic- 
sub-process tables are constructed while parsing the generic messages and generic 
sub-processes. These tables are used in expansion of the generic messages and 
generic sub-processes. The generic messages/sub-processes are expanded wherever 
they are encountered while parsing processes and sub-processes. The information 
on the processes and sub-process is stored in process-table and sub-process table 
respectively. 
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An example for expansion of a generic message : Specification of a generic 
message reg^notice is 

generic message : : 

FROM : DOAA. 

TO : * . 

msg_id : reg_notice (notice_str <STRING>). 

Action : do sub.proc store (notice.str <STRING>) . 


Specification of message send.reg-notice.to.depts that uses the generic message reg-notice 
is 


FROM : DO AA_ INTERFACE. 

TO : DOAA . 

msg_id : send_reg_notice_to_depts () . 

Action : send generic message reg.notice -[TOtDPGC, TO .constraint : (ALL)} 


After generic message expansion specification will be 


FROM 

: DO AA_ INTERFACE. 

TO 

: DOAA. 

msg_id 

: send_reg_notice_to_depts () . 

Action 

: send message reg_notice 

FROM 

: DOAA. 

TO 

: DPGC(ALL) . 

msg_id 

: reg_notice(notice_str <STRING>) . 

PRE_C0ND 

; received message send_reg_notice_to_depts . 

Action 

; do sub.proc store (notice.str <STRING>) . 
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4.1.2 Conversion 

The conversion process follows the mapping rules described in the previous chapter. 
For each class, all the sending and receiving messages are extracted from the process 
and sub-process tables. The class-table, sending message and receiving message 
tables are used for generating class declarations and possible code for methods of 
the classes. 

4.2 Inputs and Outputs 

I Input 

Input is expected in a file in the following order. 

• classes 

• generic messages 

• generic sub-processes 

• sub-processes 

• processes 


I Output 

Output of this translator consists of declarations of classes, definitions of methods 
of the classes, errors and warnings. Declaration of a class X is given in a file with 
name “X.h” and methods of this class in a file “X.c”. All errors and warnings are 
given in a file “errs.warns” 

4.3 Usage 

A file containing the specification is given to the translator : 

<prompt> translator-name <input-file> 
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Chapter 5 
Conclusions 


5.1 Conclusions 

In the previous chapters we explained how a message centric analysis / design specifi- 
cation can be translated into an implementation in C-t- f-. The translator developed 
will translate an analysis/design specification into C-f-f class headers and will 
generate possible code for methods of the classes. Associations and aggregations 
are implemented properly. A library has been developed that supports persistence 
of objects and provide routines which return pointers to required objects present in 
the .system (apj)endices A & B). Code generated is reliable as it is generated under 
the specified design constraints. 

Translation of the analysis/design specification into an implementation in RDBMS 
is described in [Vij96]. 

5.2 Exceptions 

• We assumed that all objects of the system reside on local machine. It does 
not generate code to send/receive a message to/from an object on a remote 
machine. 

• Code generated does not handle concurrency between objects. 
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• An object should have its own read and xorite methods to support persistence 
of the object (see appendix A). The definitions of these methods depend on 
type of each data member of the object. If an object contains data members 
of user defined type(date, table, list etc,. ), the generated read and write 
methods have to be modified to handle such user defined data types. 

• The key words of the specification language should not be used as names of 
classes, messages, attributes, or parameters. 


5.3 Future Work 

The specification language can be improved to represent an object oriented dis- 
tributed system. This work can be extended to generate code which provides object 
location transparency and handles concurrency between objects. 
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Appendix A 

Persistence Library 


The 00 language C++ does not support the persistent objects. We have to use 
a library that provides persistent objects. We developed a library that uses the 
ndbm.h library, a library available in unix, to store and retrieve the objects. We 
developed a persistent class which makes its derived classes persistent. 

A.l Object Id 

Each object should have a key field that can identify this object uniquely in the 
inheritance hierarchy of this object. .\nd a method that returns the object key is to 
be defined in each object class. 

A. 2 Persistent Class 

The Persistent Class is an abstraction for all Persistent Objects which inherit from 
it for persistence support. The persistent class provides methods to save, retrieve 
and remove an object from the disk. The Persistent Class expects the following 
methods to be overridden in the class that wants to be persistent. 


• GetInfo() 

• Write(ostrstream k) 
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• Read(istrstream &) 

• GetKeyField 

Getinfo For each cla^s, a file is used to store all its objects. VVe can use the name 
of the class as the file name. Each class should have a static object member 
of type Info. Info is a friend class to the Persistent Cleiss. The constructor 
of class Info takes the file name and opens the database, the destructor closes 
the database. The method Getinfo gives out a reference to this static object. 
The Persistent Class uses this method. 

Write The data of an object is packed in a string and stored under it’s key. How 
to pack the data in a string is to be defined by each object in the method 
Write (ostrstream &}. 

Read In the retrieval of an object, a string of bytes is retrieved and the data 
members of the object are to be constructed from the string of bytes. How to 
convert this data string into data members is to be defined by each object in 
the method Read(istrstream &). 

GetKeyField This method returns the key of the object. It return a pointer to a 
char string. 

A. 3 Packing data members of an object 

In saving an object to disk, all data of the object is converted into a string of bytes 
and this string of bytes is stored on disk. While retrieving, a string of bytes is 
retrieved and converted to data members of the object. 

In this section we give headers of some functions. These functions are used to 
write a data member of an object to a string of bytes and to read a data member 
from the string of bytes. 
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A. 3.1 Data Members of Primitive Type 

All the following functions return the number of bytes read(write) from(to) string 
stream. 

I WriteNumber 

The number to be written to a string can be of any type(int, unsigned int, short int. 
long int, float, double). 

template<class Type> 

int WriteNumber (ostrstream &os. Type number) 


I ReadNumber 

The number to be read from a string can be of any type(int, unsigned int, short int, 
long int, float, double). 

template<class Type> 

int ReadNumberCistrstream Stis, Type ftnumber) 


I WriteCiiar 

The char to be written to a string can be of any type(char, unsigned char). 
template<class Type> 

int WriteChar (ostrstream 4os, Type character) 


I ReadChar 

The char to be read from a string can be of any type(char, unsigned char). 
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template<class Type> 

int Read.ClxarCos'trstrGain &is. Type ftcharacter) 

I WriteString 

int WriteStringCostrstream &os, char *str) 

I ReadString 

Required memory for "str” is allocated inside the function, 
int Readstring (istrst ream &is, char *ftstr) 

A. 3.2 Data members of complex type 

The data present in the data structures like array, linked lists etc,, can be converted 
into a string using the above write functions. The data string can be formatted into 
the data structure using the above read functions. 

Eg: 

/* This function converts a list ( List<Type> ) of node type (int, short int, long 
int, double, float, char) into data string */ 

template <class InfoType> 

int HriteListOfNumbers(List<InfoType> *list,ostrstream 4 os) 

{ 

int totalBytes =0; // total bytes stored 

int noElements; 
if (list == NULL) { 

noElements = 0; //no elements in the list 
totalBytes += WriteNumber(os, noElements); 
return totalBytes; 
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} 

no El 606111:3 = list; -> Ge1:NoEl6ni6nts() ; // n'uiBb6r of 6l6iii6nts in th.6 list 
totalBytes += WriteNumber(os, noElomonts) ; 

Nod6<InfoTyp6> ♦h6a<i = list -> GatHaaderO ; 
whilaCliead) ■[ 

InfoType elm = head->GetInfo() ; 
totalBytes += WriteNumberCos, noElements) ; 
head = head -> GetNextO; 

} 

return totalBytes; // return total number of bytes saved 

} 

/* This function retrieves lists ( List<Type> ) of node Type (int, short int, long 
int, double, float, char) from the data string */ 

template <class InfoType> 

int ReadListOfNumbers( List<InfoType> *&list, // retrieved list 

istrstream & is 

) 

int totalBytes = 0; 
int noElmnts = 0; 

totalBytes += ReadNumber(is,noElmnts) ; 

if (noElmnts == 0) list = NULL; // Zero elements in the list 
else list = new List<InfoType>; // create new list 
for (int i=0;i < noElmnts ;i++) { 

InfoType ele; 

totalBytes += ReadNumber(is,elm) ; 

list -> Append(ele); // appending to list 

} 

return totalBytes; // total bytes retrieved 
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A.4 An example persistent class 

This example code of a Course class shows the supplementary code needed to support 
object persistence. 

class Course : public Persistent { 
public: 

Course 0 

SetKeyField(char *cName) ; 

char *GetKeyField() { return courseName; )• 

Read (istrst ream &) ; 

Write(ostrstream &) ; 

Info GetInfoO { return infoObjectl; } 
private; 

char *courseName; 
int Units; 

static Info infoObject; 

> 

Info Course: : inf oObject("Course") ; // all course object are stored in fi 

Course: : Write (ostrstream &os) { 

WriteNumberCos, Units); 

WriteStringCos, courseName); 

} 

Course: :Read(istrstreani &is) { 

/* The data members should be read in the same order in which 
* they were written 
*/ 

ReadNumber(is , Units); 

Readstring (is , courseName) ; 

} 
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The Course class inherits methods to Save, Retrieve and Remove an object from 
Persistent class. 

To save an object, the method Save of the object is to be invoked. 

Eg: 

A trivial example 

Course c( ' 'cs635’ ' ,4) ; 

c.SaveO; // the object c is stored 


To retrieve an object: create the object, set key field, and invoke the method 
Retrieve. The method Retrieve returns a positive number if object with the specified 
object-id found on the disk, otherwise it returns zero. 

Eg: 

A example to show how to retrieve an object from disk. 

Course *c: 
c = new Course; 

c->SetKeyField("cs699") ; // set object key 
if( c->Retrieve() == 0) •{ // retrieve from disk 

cout << " Object with given key not found 
delete c; 

> 
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Appendix B 
Template Library 


This library gives headers of the template functions used in the generated code. 
CreateLink 

template<class leftType, class rightType> 
void CreateLink (leftType, rightType) 


This function creates a link between two objects. Pointers to objects to be 
linked are to be passed as arguments to this function. For more information please 
see section 3.1.2. 

DeleteLink 

template<class leftType, class rightTyp6> 
void DeleteLink (leftType, rightType) 


This function deletes link between two objects. Object pointers are to be passed 
as arguments to this function. 
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GetPtrToObject 

template<class Type> 

void GetPtrToObject (char ♦Objectid, Type fcObjectPtr) 

This function gives a pointer to an object in ObjectPtr whose object key is 
Objectid. If object with specified key is not present in the system, ObjectPtr will be 
NULL. When an object wants to send a message to another object whose object-id 
is known, it gets a pointer to the receiving object using this function. 

GetPtrsToObjects 

template<class Type> 

void GetPtrsToObjects (List<Type> ftObjectPtr) 

The function gives a list of pointers to objects of specific class type. This is 
used, when a message is to be sent to some objects of a particular type that satisfy 
a condition. 

Eg 

The following call to this function gives a list of pointers to all Course objects. 

List<Course *> ♦courseObjects; 

VO id GetPt rsT oOb j ect s ( cours eOb j ect s) 


GetPtrToRelatedObjects 

teinplate<class Type> 

void GetPtrToRelatedObjects (KeysObject Aobjectlds, List<Type> fcobjPtrs) 

This function is used by an object to get pointers to its related objects of a 
particular type. Each object maintains object-ids of its related objects. For an 
example please see example 4 of section 3.4. 
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Appendix C 
Notation in BNF 


In this appendix a BNF grammar for the specification language is given. 


systemspec 

classlist 


classlist genericmsgs processlist ; 
classdecl 

classlist classdecl 


classdecl 

option_list 


I 

I 


CLASS ' : ' classname EOFLD option_list ; 

/♦nothing*/ 

TYPE ' : ' ID EOFLD option.list 

GENERALISATION_OF ’ : ' classname_list EOFLD option_list 
INHERITS ' : ' classname, list EOFLD option_list 
ATTR ' : ' attr_list EOFLD option.list 
RELATED.yiTH ’ : ' rel.list EOFLD option.list 
AGGROF ’ : ' agglist EOFLD option.list 


classneone : ID ; 

classname.list : ID 

I classname.list * ID 
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attr.list 


/* nothing */ 

1 attr 

I attr.list ’ , ' attr 

> 

attr : attribute 

I attribute attrtype /* <attr_type>*/ 

attribute ; ID ; 

attrtype : ID 

1 c_list 

I c_table 

c.table ; TABLE ' attr.list '] ’ 

> 

c.list : ’[' attrtype 

agglist ; aggof 

1 agglist ’ , ' aggof 

» 

aggof ; ID ’(' multiplicity ')' ; 

rel.list : relation 

I rel_list ’ , ’ relation 

9 

relation : ID '(' reltype ’ multiplicity 

9 

multiplicity : Imcity umcity 

I umcity 

9 

reltype : ID ; 
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umcity : 


1 


1 

CARDINALITY 

» 

Imcity : 

CARDINALITY ; 

GENERIC MESSAGES 


generiemsgs : 

/* optional */ 

1 

gen.mes sages 

1 

gen^messages : 

GENERIC.MESSAGE SEP gmsglist ; 

gmsglist : 

gmsg_decl 

1 

gmsglist gmsg_decl 

> 

gmsg.decl : 

gsender greevr nisg_id optlist ; 

gsender ; 

FROM ' : ' gen.clsname constraint EOFLD ; 

greevr : 

TO ’ : ' gen.clsname constraint EOFLD ; 

gen_clsname : 


1 

ID 


/♦♦♦♦♦♦♦He*************************************************************** 

ORDINARY PROCESS, GENERIC PROCESS, AND SUB PROCESS 

/iitn:**>^**m***************************************************************/ 

processlist : gen.proclist sub_proclist proclist ; 

sub_proclist : /* optional */ 

1 sub_process 

1 sTib_proclist snb.process 

> 

s'ub_process • SUB_PROCESS SEP pid EOFLD niesg_seq'uence ; 
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gea_proclist 


1 

gea_process : 


varlist : 

I 

> 

proclist : 

I 

> 

process : 

I 

pid : 

mesg_sequence : 

1 

sequence : 

I 

I 

> 

if_block : 

elsepart : 

1 

I 

loop^block : 


gea.process 

gen_proclist gea_process 
/* optioaal */ 

GENERIC.PROCESS SEP pid EOFLD 
INPUTS varlist EOFLD 
mesg.sequeace 

ID 

varlist ’ , ' ID 

process 

proclist process 

PROCESS SEP pid EOFLD mesg.sequeace 

ID ; 
seqaeace 

mesg.sequeace seqaeace 

msglist /♦ seqaeace */ 

if_block 

loop.block 

IF ’(' coaditionList ’)' elsepeirt 

/* else is optioaal */ 

ELSE mesg.sequeace ’}' 

LOOP loopcoad mesg_sequence 
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loopcond : 

field listOrtable ’)' 

1 

’ ( ' conditionList ’ ) ' 

* 

field 

ID ; 

listOrtable : 

ID ; 

msglist : 

msgdecl 

1 

msglist msgdecl 

> 

msgdecl : 

sender recvr msg_id optlist ; 

sender : 

FROM ' ; ' classname constraint EOFLD 

recvr ; 

TO ’ : ’ classnaane constraint EOFLD ; 

constraint : 

/* Constraint is Optional */ 

1 

’ ( ' cond ’ ) ’ 

f 

cond : 

Ihs operator rhs 

1 

reference 

Ihs : 

ID 

1 

classname SEP ID 

» 

rhs : 

ID 

1 

classname SEP ID 

» 

reference : 

ID ; 

operator : 

EQUAL 

1 

NOT.EQUAL 

1 

LESSER 

1 

GREATER 

1 

LESSER.EQUAL 

1 

GREATER.EQUAL 
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msg_id 

message 


mesg_id 

paramlist 


param 


var 

type 


m.list 

m_table 

optlist 


I 

1 


MSG_ID ' : ' message EOFLD ; 

mesg.id *)’ 

mesg.id ’ ( * pareimlist ' ) ' 

ID ; 
param 

paramlist ' , ’ param 

var 

var '<’ type '>' /* < paramtype > */ 

ID ; 

ID 

m_list 

m_table 


’ [' type '] ' ; 

TABLE 'C' paramlist ^]' ; 
/* nothng */ 
rasg_cond optlist 
msgtype optlist 
result optlist 
action optlist 
precondoptlist 
postcond optlist 


msgtype 

msg_cond 

mcond 

precond 


MSGTYPE ID EOFLD ; 

MSG.COND ’ ; ' mcond EOFLD ; 
constraint ; 

PRE_C0ND ' : ' conditionList EOFLD ; 
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conditionList 


condition 

conditionList l_operator condition 


l_operator : AND /* M *J 

I OR /* II */ 

I NOT /* ! */ 

> 

condition : RECVD mesg_id 

I RECVD mesg.id OF proc_id 

1 RECVD RESULT.OF mesg.id 

I RECVD RESULT_0F mesg_id OF proc_id 

I DONE_SUB_PROCESS mesg.id 

I cond 

/* We are ingnoring post conditions */ 

postcond : PQST.COND pcond EOFLD ; ! 

pcond : ID ; 

result : RESULT ' : ' res EOFLD ; 

res ; attr 

I set_of_values i 

> ! 
set_of_values : ID attr_list ; 

I 

action : ACTION ' : ' action_list EOFLD ; i 

action_list : actual_action 

I action_list ' , ' actual_action 

1 

actual. act ion : DO.SUB.PROCESS sub_proc_id sub_proc_args 

1 DO_GEN_SUB_PROCESS sub_proc_id sub_proc_args gen.valiies 

1 RETREIVE res 

1 SEND.MSG mesg.id to.recvr OF proc.id 
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I SEND_MSG mesg_id to_recvr inesg_id of current proc 

1 SEND_GEN_MSG mesg_id to_recvr inputs 

I SELECT_MENU_ITEM item 


to.recvr 


/* optional */ 


1 

ID ID /* Eg: to CDGC 

gen_values 

> 

/* optional */ 


1 

value.list ')•' 

value_list 


value 


1 

value.list ’ , ’ value 

value 

9 

ID ’ : ^ replacing.val ; 

replacing. val 

: 

ID 


1 

DOLLAR ID 

inputs 

9 

input .list ; 

input .list 

: 

var.value.pair 


1 

input .list ' , ’ var.value.pair 

var.value.pair 

> 

TO ' ID 


1 

TO.CONSTRAINT constraint 

sub.proc.args 

; 

/♦ no args for sub.process ♦/ 


1 

’ ( ' paramlist ’ ) ' 

sub.proc.id 

9 

ID ; 

proc. id 

* 

ID ; 

item 

; 

ID ; 
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